In electronics, a hardware description language (HDL) include a computer or modeling language for formally describing and designing electronic circuits, and most-commonly, digital logic. Typically an HDL can describe the circuit's operation, its design and organization, and may even define tests to verify its operation by means of simulation. Often HDLs include standard text-based expressions of the spatial and temporal structure and behavior of electronic systems. In contrast to most software programming languages (e.g., C, Java, JavaScript, etc.), HDLs often include an explicit notion of time, which is a primary attribute of hardware. Two of the more common HDLs include Verilog and VHDL (Very-high-speed integrated circuits Hardware Description Language), although other HDLs exist.
Often HDLs may be compiled into a model of their respective electrical circuits or modules. These models are occasionally referred to as Register-Transfer-Logic (RTL) models. The characteristics and functions of the electrical circuits may then be simulated via the respective RTL models. Often these RTL models are subjected to a series of tests which excite the RTL model by applying various simulated electrical signals to the RTL model and comparing the output of the RTL model to an expected output. Often these tests may also be written in a HDL or another language. Such test are typically part of the functional verification process of design in which it is determined whether or not the electrical circuit (via the RTL model) is likely to function correctly as defined by the design specification. In such an embodiment, it is easier and cheaper to fix design errors in the HDL and RTL model than to fix such errors once the electrical circuit is fabricated into a physical electrical circuit.
Modern digital circuits typically include numerous embedded memories (e.g., processor registers, instruction and data caches, random access memories, non-volatile memories, etc.) that are susceptible to soft errors. In this context, a soft error is an error in a signal or datum which is wrong. Errors may be caused by a defect, usually understood either to be a mistake in design or construction, or a broken component. In this context, a soft error is an error in a signal or datum which is wrong, but is not assumed to imply such a mistake or breakage. After observing a soft error, there is generally no implication that the system or circuit is any less reliable than before. However, while the soft error may not indicate that the circuit is damaged or incorrectly designed, a soft error may result in an incorrect calculation by the processor or larger electronic circuit.
In order to avoid undesirable behavior in the presence of soft errors, error detection (and possibly correction) logic is typically added (e.g., error correcting code, parity generation and checking, etc.). Generally such error detection is integrated or part of modern embedded memory circuits. However, the implementation of the error detection (e.g., output signals etc.) generally varies greatly from memory to memory. This logic tends to be complex, usually added late in the design cycle, and often goes untested as part of functional verification.
Although soft errors are generally rare, the handling of these errors can become critical, and untested parts of the design usually result in designs that have functional defects (a.k.a. bugs). Performing functional simulations of logic that handles soft errors is complex. Directed or targeted test simulations are generally slow, tedious, and, because of this, leaves significant portions of the electrical circuits functionality untested. For example, a tester can manually force an internal error on a specific memory instance and then verify that the appropriate action is taken (e.g., a parity error status bit is set). However, such manual simulation of an error (e.g., by manually forcing an electrical signal to a particular value, etc.) require that each test be manually coded and so tightly coupled with the tested RTL model that changes in the RTL (e.g., a change in the name of a signal, etc.) render the test invalid (e.g., the test may attempt set a signal to a high/low value but the signal may no longer exist, etc.).